嗨大家好，我是Sean! 不知道大家連假的第一天都在做些甚麼呢?
昨天我們部署完GCP後，原本今天的安排是想要做使用IIS部署專案在Window server上的教學。
但後來由於安排還有自己想嘗試一點其他的東西，所以先選擇跳過不寫，直接進入到我們的激戰篇。

順帶一提，由於需要這方面的資源以及教學好像比較少，如果有人想知道的話，可以在下面留言，特別加一篇來寫IIS!

激戰篇

那麼，我們就正式進入激戰篇。原本是想取名為實務激戰篇的，因為主要想寫一些自己在實務上碰過並解決的問題，額外再寫一些自己沒做過想挑戰的部分。但後來想想這個名字縮寫其實也是實戰篇哈哈，所以就以激戰篇代稱囉!

那麼，接下來就讓我們解決一些實務中常見的問題。我們由migration的error來開始說起。

Migration Error

https://docs.djangoproject.com/en/4.1/topics/migrations/
說到Migration error絕對是初期碰django的朋友，遇到最大的困難之一。
其中一個原因，可能沒有那麼熟悉Django的架構，以及各個部份的運作關係。

關於migration的部分，可以回去看一下我們[Day 05] 參見Django的三大將之一: Model - Migration篇
https://ithelp.ithome.com.tw/articles/10294979

那麼，我們現在來細部講解一下可能會遇到的migration error情況。

Table already exists

django.db.utils.OperationalError: (1050, "Table '' already exists")

第一種table already exists，絕對是不少見的migration error。

可能發生的情況有:

1. 當migrate檔案時發生錯誤，再次migrate就有可能產生
2. 自己使用SQL語法，直接在資料庫產生了table，再使用migrate時
3. 自行刪除了migration檔案而沒有做其他處理，再次做make migrations，migrate時

或許還有其他的可能? 以上三種是我遇過的可能的情況。
那麼我們該怎麼解決這種類型的Migrations error呢?

第一個就是像我們Day05的地方有提到的生成migration的檔案時，我們都應該要確認一下生成的內容，是否符合我們預想想要達成的結果。

特別的是，我們可以參考官方文件中，對於SQLite以及PostgreSQL都有預設啟用Transaction的功能。但在MySQL以及Oracle等無法支援DDL的資料庫，就沒有這樣的功能。
所以如果是使用MySQL的朋友，就需要特別小心有沒有錯誤migrate的可能。

第二個的話，我們如果發現有已經生成的table，不管他是因為migrate錯誤生成，還是我們用SQL語法直接在資料庫生成table，我們都可以以下面的指令來解決:

python manage.py migrate --fake

但要注意的是fake的功能使用，必須特別小心。
它主要的功能是，如字面上的感覺，假裝已經做過了這次的migrate。

那麼，我們要怎麼確認他是否有假裝完成的紀錄呢?
我們可以用以下的指令來看，我們完成的migration有哪些

python manage.py showmigraitons

它的作用是這樣的:

可以看到我們已經完成的migration會呈現 [x] 的樣子。
如果我們有一個新的migration還沒進行migrate，它就會呈現 [ ] 。

由此以來，我們就可以知道哪些migration是有遷移過的。而我們執行完fake的指令的話，在最新的migration中也會標註完成，呈現 [x] 的樣子。

好的，那麼我們今天的文章就先到此結束! 我們明天再繼續分享其他migration error的例子。
我是Sean，你各位海上的人，我們明天見!